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(54) Security system and method for financial institution server and client web browser 



(57) The financial transaction processing system in- 
cludes at least one financial server connected through 
a public network to a number of users associated with 
client computers. Each user accesses the financial serv- 
er through a web browser. The web browser is provided 
with the capabilities to generate encryption keys, to en- 
crypt and decrypt HTML forms, and to digitally sign and . 
timestamp HTML forms. The financial server transfers 
web pages including HTML forms representing financial 



transactions. The HTML forms contain extensions that 
specify the format of an incoming format and the format 
of a returned form. An HTML form can be transmitted in 
an encrypted format, in a format including a user's digital 
signature and timestamp, and in an encrypted format 
that contains the user's digital signature and timestamp. 
The financial server tracks each processed transaction 
through an audit trail including the user's account, the 
user's digital signature, the timestamp of the transac- 
tion, and the text of the transaction. 
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Description 

This invention relates to electronic communication 
systems and in particular to a method and apparatus tor 
securely transmitting transactions from an application s 
program. 

Background of the Invention 

Today, there is a great demand to support online 
financial transactions in a client/server computing envi- 
ronment. The key to the success of such systems are 
security features to ensure that an authorized party se- 
curely transmits a communication to an authorized re- 
cipient. At a minimum, five security features are needed: 
privacy, data integrity, access control, user nonrepudia- 
tion, and a server side audit trail. 

Current security technology for clients calling finan- 
cial servers include (A) systems using passwords and 
the like to indicate a client's identity, (B) systems using 
session keys to encrypt the communications between a 
client and server so that outsiders cannot eavesdrop, 
and (C) systems using a digital signature and certifica- 
tion process. 

Session key encryption provides privacy protection, 
and password mechanisms provide basic access con- 
trol capabilities. The prior art does not provide absolute 
assurance that the party claiming to be a client is in fact 
the identified client (or even that the party is using the 
client's workstation), and also does not protect the finan- 
cial institution from claims by clients that they did not 
send a particular message or request. The audit trail of 
the prior art systems will only show that the party that 
sent the message or request used the client's password 
to log in, which is often not conclusive proof. Thus, the 
financial institution is at risk of repudiation of transac- 
tions by clients. 

Furthermore, the systems (e.g., Quicken, Netscape 
and Schwab's Smart Money using RSA encryption soft- 
ware) for encrypting the communications do so at the 
TCP/IP protocol layer of each system's software. This 
type of security technology limits the type of secu rity fea- 
tures that can be provided. For instance, a security fea- 
ture at the TCP/IP protocol level, such as SSL, typically 
provides only privacy by encrypting all data transmitted, 
but it cannot authenticate the client. 

Systems utilizing client digital signatures are typi- 
cally used with digital certificates. Digital certificates re- 
quire a public key to be signed by a trusted third party. 
They are typically used to authenticate that a particular 
public key is really that of a particular user However, 
financial institutions are reluctant to utilize digital certif- 
icates since they are wary of the potential liability asso- 
ciated with their fraudulent misuse. 

Summary of the Invention 

The present invention pertains to a system and 



method for providing a secure communication mecha- 
nism between a financial server and a user associated 
with a web browser. The communication mechanism is 
used to ensure that financial transactions are securely 
transmitted between the user and server across a public 
network. The system includes a group of users associ- 
ated with client computers that are interconnected, by a 
computer network such as the Internet, to at least one 
financial server associated with a server computer. 

The financial server has a web server that manages 
the interactions between the users, through their web 
browsers, and the financial server. The web server has 
a repository of web pages associated with various finan- 
cial services provided by the financial server. The web 
pages contain HTML documents and forms represent- 
ing financial transactions that are exchanged between 
the user and the server. A user utilizes a web browser 
to access the HTML documents and to return data from 
HTML forms to the server. The server then processes 
the transactions and updates an audit trail that tracks 
each transaction. 

Due to the highly confidential nature of the transac- 
tions, the system and method of the present invention 
incorporates several security features into the web 
browser and web server. The following five security fea- 
tures are provided: privacy, in the form of session key 
encryption; data integrity, through the use of data en- 
cryption; access control, via a password mechanism; 
user nonrepudiation, by means of digital signatures and 
timestamps; and a server side audit trail. 

The web browser is provided with the capability to 
receive encrypted forms and to transmit messages con- 
taining timestamped, digitally signed, and encrypted 
form data. The web browser has the ability to provide 
each user with a pair of encryption keys, preferably a 
private and public key pair. The web browser's initializa- 
tion procedure generates these keys during installation. 
The keys are stored in an encrypted format and are only 
accessible from within the browser. The private key is 
used to digitally "sign" a transaction message when so 
requested. 

The web browser is also provided with the capability 
to generate random session keys, to decrypt HTML 
forms, and to encrypt and digitally sign and timestamp 
HTML form data. In addition, the web browser can in- 
terpret HTML extensions to the FORM tag that specify 
that an HTML form is encrypted as well as request the 
return transmission of HTML form data in one of three 
formats: (1 ) encrypted; (2) digitally signed with a times- 
tamp; or (3) encrypted and digitally signed with a times- 
tamp. 

To return the encrypted form data, the web browser 
generates a random session key that is used to encrypt 
the message containing the form data. The session key 
is affixed to the return message and encrypted with the 
server's public key. A header record is included at the 
top of the message and includes a flag indicating that 
the form data is encrypted. 
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If a form requires the user's digital signature, the 
web browser uses the user's private key to "sign" the 
returned form data and to affix a digital timestamp. The 
web server authenticates the user's digital signature 
with the user's public key. For forms requiring a digital 
signature and encryption, the web browser signs the 
form data with the user's private key and includes a dig- 
ital timestamp as well. The web browser generates a 
random session key that is used to encrypt the form da- 
ta. The random session key is affixed to the return mes- 
sage and encrypted with the server's public key. 

The web server reads the header record associated 
with a received message in order to determine the for- 
mat of the message. A flag associated with the header 
record indicates the particular format. The web server 
processes the message accordingly and updates an au- 
dit trail with the form data, the user's digital signature, 
and timestamp, if applicable. 

In order to verify a user's digital signature, a user 
registration process is performed initially by the web 
server at the time a user's account is established. The 
registration process is facilitated by a user registration 
HTML form that elicits financial data pertaining to a po- 
tential user. A user appends its public key to the regis- 
tration form data which is returned to the web server. 
The web server stores the user's public key in a data- 
base and it is used thereafter to verify the user's digital 
signature which may be embedded in subsequent trans- 
actions. 

Brief Description of the Drawings 

Examples of the invention will now be described in 
conjunction with the drawings in which: 

Fig. 1 shows a financial transaction processing sys- 
tem according to an embodiment of the present inven- 
tion. 

Fig. 2 shows a server computer system according 
to an embodiment of the present invention. 

Fig. 3 shows a client computer system according to 
an embodiment of the present invention. 

Fig. 4 shows a format of an audit trail residing in the 
server computer 

Fig. 5 shows a return message layout in accordance 
with an embodiment of the present invention. 

Fig. 6 shows the record layout of the header record 
of the return message of Fig. 5. 

Fig. 7 is a schematic representation of an exempla- 
ry HTML FORM tag used in connection with a user reg- 
istration form. 

Fig. 8 is a schematic representation of an exempla- 
ry HTML FORM tag including additional fields that indi- 
cate the format of incoming forms and return messages. 

Fig. 9 is a flow chart of the steps used in the financial 
transaction processing system embodying the present 
invention. 

Fig. 10 is a flow chart of the steps used by the web 
browser to establish encryption keys for a user* 



Fig. 11 is a schematic representation of an exem- 
plary web page used by the web browser to initiate the 
generation of a user's encryption keys. 

Figs. 1 2A - 1 2B are flow charts of the steps used by 
5 the financial server in communicating with users asso- 
ciated with client computers. 

Fig. 1 3 is a flow chart of the steps used by the web 
browser in processing a user registration HTML form. 
Fig. 14 is a schematic representation of an exem- 
io piary user registration HTML form. 

Figs. 1 5 A - 1 5B are flow charts of the steps used by 
the web browser in processing HTML documents. 



Overview 

Referring to Fig. 1 , the present invention pertains to 
20 a distributed financial transaction processing system 
100 and method including at least one financial server 
associated with a server computer 102 in communica- 
tion with a number of users associated with client com- 
puters 106. 

25 The financial server 102 provides various financial 
services which are offered by a financial institution such 
as a bank, insurance company, brokerage firm, credit 
union, and the like. The financial services can include 
an online trading service, means for obtaining invest- 

30 ment product information or financial news, means for 
monitoring a user's portfolio holding, and the like. 

Users connected to the financial server 102 can re- 
quest any one of the financial services. One or more web 
pages are associated with a service and are download- 

35 ed to the client computer 1 06 at the user's request. The 
web pages can include HTML documents 124 contain- 
ing HTML forms used to elicit information from the user 
106 that is transmitted to the server 102 or to provide 
information to the user 106 from the server 102. In ad- 

40 dition, the financial server 1 02 contains an audit trail 1 22 
that tracks each transaction. 

In certain cases, the HTML forms 124a can be 
transmitted to the web browser 216 in an encrypted for- 
mat or without any special formatting. The web browser 

45 returns messages 1 43 containing form data to the finan- 
cial server 102 in an encrypted format, a format contain- 
ing the user's digital signature and timestamp, an en- 
crypted format containing the user's digital signature 
and timestamp, or without any special formatting. The 

so web browser 216 has the capability to recognize special 
extensions to the HTML FORM tag that indicate the for- 
mat of the incoming document and specify the format of 
the data to be returned. An alternate embodiment might 
specify extensions to other HTML tags. 

55 in addition, the web browser 216 is equipped with 
encryption procedures 220, timestamp procedures 228, 
digital signature procedures 230, and random key gen- 
eration procedures 232. The random key generation 
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procedures 232 are used to generate session keys that 
are used in conjunction with the encryption procedures 
220 to encrypt a return message. The digital signature 
230 and timestamp 228 procedures enable the web 
browser to digitally sign and timestamp a return mes- 
sage 143. In addition, the initialization procedures 226 
enable the web browser 216 to generate encryption 
keys 218 that are used to represent and verify a user's 
digital signature. 

System Architecture 

Referring to Fig. 2, there is shown a distributed com- 
puter system 100 according to an embodiment of the 
present invention. The system 1 00 includes one or more 
server computers 1 02 and one or more client computers 
106 that are in communication with each other through 
a communication link 104. Preferably, the communica- 
tion link 104 is a public network such as the Internet. 

A server computer 102 includes a central process- 
ing unit (CPU) 108, a user interface 110, a communica- 
tions interface 112, and a primary memory 114. The 
communications interface 112 is used to communicate 
with other user workstations as well as other system re- 
sources not relevant here. 

The primary memory 114 of the server computer 
102 may be implemented as RAM (random access 
memory) or a combination of RAM and non-volatile 
memory such as magnetic disk storage. The primary 
memory 1 1 4 of the server computer 1 02 can contain the 
following: 

• an operating system 116; 

• Internet access procedures 118; 

• Web server procedures 120; 

• an audit trail 1 22 tracking each financial transaction 
processed by the financial server 1 02; 

• an HTML document repository 124; 

• an encryption procedure 1 26 for encrypting and de- 
crypting data; 

• a digital signature procedure 128 for signing and 
verifying a digital signature; 

• a user database 1 32 storing information associated 
with each user; 

• one or more encryption keys 142 for use by the 
server; 

• messages 143; 

• as well as other data structures and procedures. 
The user database 132 can store the following: 

• an account identifier 134; 

• a password 136; 

• one or more of the user's encryption keys 1 40 that 
are used to authenticate a user's digital signature; 
and 

• as well as other data structures and procedures. 



Referring to Fig. 3, a client computer 106 includes 
a centra! processing unit (CPU) 202, a user interface 
204, a communications interface 206, and a primary 
memory 208. The communications interface 206 is used 
s to communicate with other user workstations as well as 
other system resources not relevant here. 

The primary memory 208 of the client computer 1 06 
may be implemented as RAM (random access memory) 
or a combination of RAM and non-volatile memory such 
as magnetic disk storage. The primary memory 208 of 
the server computer 102 can contain the following: 

an operating system 210; 
network access procedures 212; 
an HTML document repository 214; 
a web browser 216; 
messages 143; 

as well as other data structures and procedures. 
The web browser 216 can contain the following: 

• one or more user encryption keys 218 associated 
with the user's digital signature; 

• an encryption procedure 220 for encrypting and de- 
crypting data; 

• a random key generation procedure 222 for ran- 
domly generating session keys; 

• a formatting procedure 224 for configuring a return 
message in a requested manner; 

• an initialization procedure 226 that establishes the 
user's encryption keys 218; 

• timestamp procedures 228 that generate a times- 
tamp representing a time and date; 

• digital signature procedures 230 that are used to 
sign a form and verify a user's digital signature; 

• the user's password 232; 

• a browser welcome web page 234; 

• a browser's encryption key 240 that is used to en- 
crypt the user's encryption keys 218; 

• one or more session keys 241 for use in encrypting 
return messages to the server; 

• as well as other data structures and procedures. 

File Formats 

The present embodiment utilizes an audit trail and 
a form file having prescribed formats. Fig. 4 represents 
a format of the server's audit trail 122. The audit trail 122 
is used to track each transaction that is processed by 
the financial server 1 02. The audit trail 1 22 serves a va- 
riety of purposes. One such purpose is to verify client 
messages and requests. Each communication initiated 
by a client and received by the financial server 102 is 
recorded in the audit trail 122. 

Each entry 242 in the audit trail 122 can contain an 
account identifier 243 associated with a particular user, 
the digital signature 244 associated with a particular us- 
er, a timestamp 245 representing the date and time at 
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which the user digitally signed the transaction, and the 
text 246 associated with the transaction. In some cases, 
a transaction form will contain the user's digital signa- 
ture and timestamp. In these cases, the user's digital 
signature and timestamp can be used to refute potential 
repudiation claims by the user. The existence of the us- 
er's digital signature and timestamp signifies that a par- 
ticular user executed the transaction and at a certain 
date and time. The ability to refute repudiation claims is 
sometimes called "non repudiation." 

The benefit of this embodiment is that it helps re- 
duce fraud and errors in three ways. First, it prevents 
unauthorized users from forging transactions. Second, 
it makes it difficult for a user to repudiate a transaction 
that has actually been made. Lastly, audit trail entries 
are potentially useful as judicial evidence. Furthermore, 
the security features of this invention benefit companies 
such as Charles Schwab that offer securities and finan- 
cial transaction services over the Internet. 

It should be noted that, in the description above, the 
timestamp stored in the audit trail was actually generat- 
ed by the client. It is possible for this timestamp to be in 
error, either because of a configuration problem (e.g., 
the user's PC had its clock set wrong) or because of 
fraudulent intent on the part of the user. The timestamp 
stored in the audit trail is thus merely the client's asser- 
tion as to the time at which the transaction was made. 
The server has several options available that can in- 
crease the trustworthiness of the audit trail entries. The 
server can store a timestamp of its own along with the 
client-supplied timestamp in the audit trail. Or, the server 
can reject transactions whose timestamps differ from 
the current actual time by a significant amount. Another 
possibility is for the server to generate a timestamp and 
send it to the client in another extension to the HTML 
FORM tag. The client would include the server-gener- 
ated timestamp as part of the return message. Still an- 
other possibility would be for the server to generate a 
timestamp and to digitally sign it before sending it to the 
client. All of these possible embodiments increase the 
trustworthiness of the timestamps in the audit trait, thus 
serving to increase the usefulness of the audit trail in 
reducing fraud and errors. 

This embodiment employs digital signatures and 
encryption without using authentication certificates. Us- 
ing digital signatures and encryption without authentica- 
tion certificates offers several advantages over the prior 
art use of authentication certificates. Setting up the au- 
thentication certificate infrastructure is very time-con- 
suming and costly. The process of issuing certificates is 
very cumbersome. Authentication certificates are useful 
in cases where more than two parties are involved in a 
transaction. The techniques employed in this embodi- 
ment are effective for two-party transactions, such as 
between a financial institution and one of its customers. 
Furthermore, these techniques avoid the expense of 
setting up the authentication certificate infrastructure as 
well as avoiding the overhead of certificate issuance and 



maintenance. 

Figs. 5 and 6 illustrate the return message layout 
that the web browser utilizes in returning a message 1 43 
back to the server 102. The return message 143 con- 

s tains a header record 252 containing an account iden- 
tification (ID) field 257, a flag field 258 and a key length 
field 260. The flag field can take on the following values: 
"E", representing an encrypted format; "S", indicating 
that the form data 256 contains a digital signature and 

io atimestamp; "A", representing an encrypted format con- 
taining a digital signature and timestamp; and n N B , rep- 
resenting no special formatting. The key length field 260 
indicates the length of a random session key when en- 
closed. 

is The second record of the return message 143 can 
be the random session key 254. This key 254 is en- 
closed in the return message whenever the form data 
256 is encrypted. In cases where the data is not trans- 
mitted in an encrypted format, no session key is included 

20 in the form file. The third portion of the return message 
143 contains the form data 256. The form data 256 is 
formatted as indicated in the flag field 258 of the header 
record 252. 

It should be noted that the present invention is not 
25 limited to the file formats and contents as previously de- 
scribed. Other formats can be used that can include dif- 
ferent contents. 

HTML Extensions 

30 

The present embodiment employs extensions to the 
HTML FORM tag. one set of extensions pertains to 
processing the user registration HTML form 264. This 
form is used to transmit the server's public key to the 

35 user and for the user to transmit to the server the user's 
public key. A second set of extensions is used to indicate 
the format of received and transmitted HTML forms and 
return messages. 

Fig. 7 shows the extensions to the HTML FORM tag 

40 associated with a user registration form 268. The first is 
the request field (e.g., request = "register") which is 
used to indicate the type of form that follows. A value of 
reg/ster indicates that the form is a registration form. The 
second new field is the key field (e.g., key = "server's 

45 public key") which is used to indicate the server's public 
key. The server's public key is used in the encryption 
process associated with the returned user registration 
message. 

Fig. 8 illustrates the extensions to the HTML FORM 
50 tag that are used to indicate the format of incoming (i. 
e., received by the web browser) forms or outgoing (i. 
e., transmitted by the web browser to the server) mes- 
sages. The HTML FORM tag can include an outformat 
and an informat field. The outformat field specifies the 
55 format of the return message and the informat field 
specifies the format of the incoming or received form. 
The values for the informat field can include "encrypt" 
indicating that the incoming form associated with the 
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FORM tag is encrypted. The values for the outformat 
field can include "encrypt", "sign", or "ensign." The "en- 
crypt" value signifies that the form data is to be returned 
in an encrypted format. The "sign" value signifies that 
the returned form data is to include the user's digital sig- . 
nature and timestamp. The "ensign" value signifies that 
the returned form data is to be encrypted and include 
the user's digital signature and timestamp. 

In addition, the key field can be used to transmit a 
server's encryption key along with the informat and out- 
format field. The server's public key is transmitted to the 
web browser in order for the public key to be used to 
encrypt the session key. In one embodiment, the serv- 
er's public key can be included in each HTML form that 
requires encryption. In another embodiment, the serv- 
er's public key can be included in the first HTML form 
transmitted to the user. It is retained by the web browser 
for the duration of the session. This obviates the need 
to retransmit the server's public key with each subse- 
quent transmission. 

The HTML forms emanating from the financial serv- 
er can contain any combination of the above mentioned 
new fields in a FORM tag. Furthermore, the present em- 
bodiment can also accommodate a version of HTML 
that does not incorporate any of the new fields. 

Although the present embodiment has been de- 
scribed with reference to a particular syntax for the new 
field in the HTML FORM tag, it is not limited to this par- 
ticular embodiment. Any other syntax can be used pro- 
vided that it provides a similar function. In addition, the 
present invention can be achieved using different HTML 
tags or through the use of new HTML tags. 

The general architecture associated with the 
present embodiment has now been disclosed. Attention 
presently turns to a more detailed consideration of the 
architecture of the embodiment, the processing per- 
formed by the embodiment, the distinctions between the 
elements of the architecture, and the advantages asso- 
ciated with the disclosed technology. 

Financial Transaction Processing Overview 

Fig. 9 illustrates the steps used in the financial 
transaction processing system 100 and method of the 
present invention. Initially, a user associated with a cli- 
ent computer 106 installs a web browser 216 that gen- . 
erates a pair of encryption keys 218 (step 226). Prefer- 
ably, a private/public key pair 218 is created where the 
private key is used by the user to digitally sign forms and 
the public key is used by the server to authenticate the 
user's digital signature. 

A user establishes an account 1 34 with the financial 
server 102. This account 134 is established through a 
user registration HTML form 264 that is transmitted to 
the user when the user initially accesses the financial 
server 102 (step 274). The user registration HTML form 
264 elicits general and financial data from the user as 
well as the user's public key 140. 



Once the user has established an account 1 34 with 
the financial server 102, the user can logon or access 
the account 1 34 at various times (step 276). During each 
logon session, the user and financial server 1 02 can ex- 
5 change HTML transaction forms 124 and forms data 
143 (step 278). The format of the forms varies depend- 
ing on the transaction type. In some cases, the server 
102 can transmit to the user an encrypted form. In other 
cases, the server 1 02 can request that the web browser 
216 return a message in a number of formats. At the 
completion of a particular session, the user exits (step 
280) and can reactivate another session with the finan- 
cial server 102 at a later time. 

Each of the aforementioned processes will now be 
described below in more detail. 

The Web Browser Initialization Procedure 

Initially before the financial transaction system 100 
is initiated, a user installs a web browser 21 6 in the client 
computer 106. As part of the web browser's installation 
process, an initialization procedure 226 executes which 
generates one or more encryption keys 218. Preferably, 
a private and public key pair are generated. The private 
key is used to create the user's digital signature and the 
public key is used to verify the user's digital signature. 

Referring to Figs. 10 and 11, the initialization pro- 
cedure 226 displays a browser welcome page 234 (step 
300). The initialization procedure 226 prompts the user 
for the password 232 associated with the browser 216 
and verifies it (step 302). Upon successful verification, 
the user's private/public encryption keys 21 8 are gener- 
ated (step 304) and, optionally, displayed to the user 
(step 306). Any of the well known encryption techniques 
can be used to generate the encryption keys 218. En- 
cryption techniques are described in Schneier, Applied 
Cryptography, John Wiley & Sons, 2d ed., 1 996, which 
is hereby incorporated by reference as background in- 
formation. 

The initialization procedure 226 then encrypts the 
user's encryption keys 218 using the browser's encryp- 
tion key 240 (step 308) to protect those keys from mis- 
use or misappropriation, and stores them in a prede- 
fined location within the web browser's address space 
(step 310). 

Financial Server Processing 

Figs. 12A - 12B illustrate the steps used by the fi- 
nancial server 102 in processing requests and transac- 
tions from the users. A user accesses the financial serv- 
er 1 02 by means of an account identifier 1 34 and a pass- 
word 136 (step 320). The financial server 102 verifies 
the account 134 and its password 136 (step 322). This 
verification can be performed by matching the account 
1 34 and password 1 36 against the data in the user da- 
tabase 132. If the financial server 102 has determined 
that the user is new (step 324-Y) it transmits a user reg- 
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istration form 264 to the user (step 326). The details of 
the user registration procedure is described in detail be- 
low with reference to Fig. 13. 

Otherwise, the user has an established account 1 34 
with the financial server 102 (step 324-N). The financial 
server 1 02 awaits for transmissions from the client (step 
328). The transmissions can be requests for web pages, 
form data, as well as other types of communications. 
The financial server 102 identifies the type of transmis- 
sion received from the client (step 330) and processes 
it accordingly. 

If the transmission was a request for one or more 
web pages, the financial server 1 02 obtains the request- 
ed web page and transmits them to the user (step 334). 
The web pages can contain HTML forms that are en- 
crypted (e.g., documents with confidential information 
are encrypted). The encrypted forms are identified by 
special fields in the FORM tag as was described above 
previously with reference to Fig. 7. Messages with con- 
fidential user information sent by a client to the server 
are preferably encrypted with a session key. Forms sent 
by the server to a client are preferably encrypted by the 
server with the client's public key, because any form or 
document encrypted with the client's public key can be 
decrypted and viewed only by a person or system hav- 
ing access to the client's private key. 

Alternately, forms containing confidential informa- 
tion sent by the server to a client can be encrypted with 
a session key generated by either the server or client. 
If the session key is generated by the server, the session 
key is encrypted with the client's public key, attached to 
the encrypted form being sent to the client. In this em- 
bodiment, the client first decrypts the session key with 
its private key and then decrypts the form with the ses- 
sion key. Session key encryption is often preferred for 
encrypting documents (as opposed to short messages) 
because it is typically performed using encryption tech- 
niques (such as DES) that are much less computation- 
ally expensive than public/private key encryption. 

I n yet another alternate embodiment, the server can 
utilize a different pair of public/private encryption keys 
for each user. In another alternate embodiment, the 
server can utilize a different pair of public/private en- 
cryption keys for each user for each logon session. 

If the transmission is a return message, the flag field 
258 of the header record 252 associated with the mes- 
sage is decoded in order to identify the format type (step 
332). For an encrypted message (i.e., flag="E D ), the 
server's private key 1 42 is used to decrypt the encrypted 
session key 254 (step 336). The session key was en- 
crypted by the user's web browser 216 with the server's 
public key. The session key 254 is then used to decrypt 
the enclosed form data 256 (step 338). The server's au- 
dit trail 1 22 is then updated with the user's account and 
the form data 256 (step 340). The form data 256 is then 
processed accordingly (step 342). 

For an encrypted message that contains the user's 
digital signature andtimestamp (i.e., flag="A"), the serv- 



er's private key 1 42 is used to decrypt the embedded 
session key 254 (step 344). The session key 254 is then 
used to decrypt the enclosed form data 256 (step 346). 
Next, the user's digital signature 218 is located within 
s the message and verified with the user's public key 1 40. 
The timestamp associated with the user's digital signa- 
ture is also extracted from a predefined location within 
the message (step 348). The user's public key 140 is 
obtained from the server's user database 1 32. The fi- 
io nancial server 1 02 searches the user database 1 32 us- 
ing the account ID field 257 of the header record asso- 
ciated with the message. The audit trail 1 22 is then up- 
dated with the user's account, digital signature, times- 
tamp, and the form data (step 350). The form data is 
is then processed accordingly (step 352). The procedure 
then awaits for a new client communication. 

An incoming message 143 that contains the digital 
signature of the user (i.e., flag^S") is processed using 
some of the same steps as a message that is encrypted 
with the user's digital signature and timestamp. The fi- 
nancial server 102 locates the digital signature of the 
user within the message which is verified with the user's 
public key 140 (step 348). The audit trail 122 is then up- 
dated with the user's account, digital signature, times- 
tamp, and the form data (step 350). The form data is 
then processed accordingly (step 352). The procedure 
then awaits for a new client communication. 

For messages that are not received in a special for- 
mat (i.e., messages that are received in a non-encrypt- 
ed, plain format), the audit trail 122 is updated with the 
user's account and the form data 256 (step 350). The 
form data is then processed accordingly (step 352). The 
procedure then awaits for a new client communication. 

Servers User Registration Procedure 

Fig. 1 3 illustrates the steps used by the web brows- 
er 21 6 in processing a user registration form 264 shown 
in Fig. 14. The web browser 216 receives an HTML doc- 
ument containing a user registration form 264 from the 
financial server 102 (step 360). 

The user registration form 264 includes data entry 
fields that the user fills in (step 362). The web browser 
inserts into the registration form user information {pro- 
vided by the user of the client computer and/or available 
to it from other resources in the client computer), typi- 
cally including data that uniquely identifier the user such 
as the user's name, social security number or equivalent 
identifier, and the financial institution account number 
for an account previously established by the user with 
the financial institution associated with the server. 

The web browser 216, having identified the form as 
the user registration form from the request field of the 
FORM tag (i.e., request^register"), obtains the user's 
public encryption key 21 8 and places it into a predefined 
location within the return message (step 364). The us- 
er's public key 218 is stored in an encrypted format in a 
specified location within the web browser's address 
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space. The user's encryption keys 218 were encrypted 
with the browser's encryption key 240. Thus, the web 
browser decrypts the key from the known location with 
its own encryption key 240. 

The web browser 216 then uses the digital signa- 
ture procedures 230 to digitally sign the form data with 
the user's private key 218 (step 366). Next, the web 
browser 216 uses the random session key generation 
procedures 222 to generate a random session key 254 
(step 368). The random session key 254 is used to en- 
crypt the form data (step 370). The session key 254 is 
affixed to the top of the message and encrypted with the 
server's public key 142. The server's public key 142 is 
transmitted through the key field in the FORM tag (i.e., 
key = "server's public key") (step 372). The return mes- 
sage is then formatted using the formatting procedures 
224 and transmitted to the server (step 374). 

A random session key is a random-bit string gener- 
ated by means of a random process. Typically, the key 
bits are generated from a reliably random source or a 
cryptograph ically secure pseudo-random bit generator 
Any of the well known random sequence generators can 
be used. A description of these techniques can be found 
in the Schneier reference previously mentioned with re- 
spect to Figs. 1 0 and 1 1 . 

The server decrypts and verifies the information in 
the received registration message. If the information 
satisfies predefined acceptance criteria, such as match- 
ing user information associated with a previously estab- 
lished account at the financial institution, then a user in- 
formation record is added to the user database 132. As 
shown in Fig. 2, the user information record identifies 
the user and the user's public key. Alternately (e.g., if 
the server's database 1 32 already contains user records 
for every user having an account at the associated fi- 
nancial institution), a previously existing user informa- 
tion record is updated to include the user's public key. 

Web Browser 

Once the user is registered with the financial server 
102, the user, through the web browser 21 6, exchanges 
HTML transaction forms and return messages with the 
financial server 102. At least some of the HTML docu- 
ments sent by the server to a client will contain an HTML 
FORM tag. In accordance with a preferred embodiment, 
the FORM tag includes special fields that indicate how 
the associated HTML document is formatted (e.g., 
whether or not it is encrypted). If the HTML document 
sent by the server to a client is encrypted, a special "key" 
field in the FORM tag can be used to specify the server's 
public key. If the form is of the type that requests user 
information be returned to the server, the FORM tag also 
includes special fields that instruct the client's Web 
browser as to how the return message should be for- 
matted before it is returned to the server. The client's 
web browser 216 reads these FORM tag fields and per- 
forms the appropriate procedures to enable the user to 



read the HTML document and to properly format the 
message for transmission back to the server. 

Figs. 1 5 A - 1 5B illustrate the steps used by the web 
browser 216 in processing HTML documents that are 
s received from the financial server 102. Upon receipt of 
an HTML document (step 380), the web browser 216 
inspects the fields of the FORM tag. If the FORM tag 
indicates that the form associated with the tag is en- 
crypted (i.e., the existence of an informat field) (step 

to 382- Y), the web browser 216 recognizes that the data 
contained between the FORM tag pairs is encrypted. 
The web browser 216 reads the data from the file until 
it reaches the corresponding FORM tag pair (i.e., <J 
FORM>) (step 41 4). The web browser 216 decrypts the 

is form with the user's private key 218 (step 41 6) and con- 
tinues to read the tags in the HTML document. 

Next, the web browser 216 detects if the FORM tag 
has an outformat field (step 384). If the FORM tag does 
not include an outformat field (step 384-N), the form is 

20 displayed and processed accordingly (step 386). Other- 
wise (step 384-Y), the outformat field is stored and the 
form is displayed and processed accordingly (step 388). 

Once the form has been processed, the web brows- 
er 21 6 prepares the return message in accordance with 

25 the requested directives specified in the stored outfor- 
mat field (step 390). 

If the requested return message format specified 
encryption with a digital signature and timestamp (i.e., 
outformat = "ensign"), the web browser 216 digitally 

30 signs the form data with the user's private key 21 8 and 
appends a timestamp at a predefined location within the 
message (step 392). Next, the web browser 216 ran- 
domly generates a session key 254 (step 394). The 
message is then encrypted with the randomly generated 

35 session key 254 (step 396). In some embodiments, a 
single session key is used for all encrypted client mes- 
sage transmissions during a single session, in which 
case step 396 is skipped after the transmission of the 
first encrypted client message during a session. 

40 The session key 254 is encrypted with the server's 
public key 142 and affixed to the encrypted message 
(step 398). As noted above with respect to Fig. 8, the 
server's encryption key is transmitted to the web brows- 
er either initially with the first transmitted HTML form or 

45 with each transmitted HTML form requiring encryption. 
A header record 252 is then generated containing 
a flag 258 having the appropriate value ("A") and the 
key length 260 of the enclosed session key 254. The 
message is formatted and then transmitted to the finan- 

50 cial server 102 (step 400). 

If the requested return message format specified 
encryption (i.e., outformat = "encrypt"), the web browser 
216 performs some of the same steps described above. 
The web browser 216 randomly generates a session 

55 key 254 (step 394). The form data is then encrypted with 
the randomly generated session key 254 (step 396). 
The session key 254 is affixed to the encrypted form da- 
ta and encrypted with the server's public key 142 (step 
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398). A header record 252 is then generated containing 
a flag 258 having the appropriate value ("E") and the 
key length 260 of the enclosed session key. The mes- 
sage is formatted and then transmitted to the financial 
server 102 (step 400). 

If the requested return message format specified 
the user's digital signature (i.e., outformat = "sign"), the 
web browser 21 6 signs the form data with the user's pri- 
vate key 21 8 (step 410). In addition, a timestamp is gen- 
erated and appended to the form data (step 410). A 
header record 252 is then generated containing the ap- 
propriate flag value ("S"). Since no session key is en- 
closed in the message, the key length field is blank. The 
message is formatted and then transmitted to the finan- 
cial server 102 (step 412). 

In conclusion, the aforementioned description de- 
scribes a method and system for securely transmitting 
transactions embodied as HTML forms between a finan- 
cial server and a web browser. The technology of the 
present embodiment incorporates five security features 
to ensure that only the intended parties of the transac- 
tion securely receive and transmit a transaction. The five 
security features include: privacy, in the form of session 
key encryption; data integrity, through the use of data 
encryption; access control, via a password mechanism; 
user non repudiation, by means of digital signatures and 
timestamps; and a server side audit trail. These security 
features are embedded in the financial server and web 
browser in an automatic and transparent manner. 

Alternate Embodiments 

The method and system described hereinabove is 
amenable for execution on various types of executable 
mediums other than a memory device such as a random 
access memory. Other types of executable mediums 
can be used, such as but not limited to, a computer read- 
able storage medium which can be any memory device, 
compact disc, or floppy disk. 

Although the embodiments have been described 
with reference to encryption and digital signature tech- 
niques that utilize encryption key pairs, it is not limited 
to this particu lar techn ique. Any technology or technique 
that provides similar functionality can be utilized. 

Furthermore, one skilled in the art can easily modify 
the embodiment to incorporate a digital signature mech- 
anism in the HTML forms that are transmitted to a web 
browser. Moreover, additional security features can be 
easily added to either the client or server side of the 
transaction processing. 



Claims 

1 . A computer-implemented method for transmitting fi- 
nancial transactions between at least one client 
computer and at least one server computer inter- 
connected by a communications link, the method 



comprising the steps of: 

(a) receiving one or more HTML documents 
from the server computer, a subset of the doc- 

5 uments including format directives, each of a 

first subset of the format directives indicating 
an outgoing transmission format used in trans- 
mitting a return message to the server compu- 
ter, each of a second subset of the format di- 

io rectives indicating an incoming transmission 

format used to receive an HTML document, 
each of the first and second subsets of format 
directives associated with at least one crypto- 
graphic technique; 

is (b) inserting form data from a received HTML 

document into said return message; 

(c) applying one or more cryptographic tech- 
niques to the form data, each applied crypto- 
graphic technique identified in a respective for- 

20 mat directive associated with the received 

HTML document; and 

(d) transmitting the return message to the serv- 
er computer. 

25 2. The method of claim 1 , 

the format directives selected from the set 
consisting of encryption, digital signature and 
timestamp, and encryption with digital signature 
and timestamp. 

30 

3. The method of claim 1 , 

step (c) further including the steps of: 

(1 ) generating a first encryption key; 
35 (2) encrypting the form data, including any in- 

serted user related information, with the first 
encryption key; 

(3) affixing the first encryption key to the return 
message; and 

40 (4) encrypting the first encryption key with a 

second encryption key. 

4. The method of claim 3, 

step (c)(1) further including the step of utiliz- 
es jng a random key sequence generator to generate 
the first encryption key. 

5. A web browser for accessing data within a computer 
system including at least one client computer con- 

so nected through a communications link with at least 
one server computer, the browser comprising: 

a memory for storing a plurality of HTML docu- 
ments, a subset of the HTML documents in- 
55 eluding cryptographic protocol directives for 

use in returning form data included in said 
HTML documents; 

browsing mechanism for retrieving various 
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ones of the HTML documents from the server 
and for inserting user related information in said 
form data which is included in a return mes- 
sage; and 

a cryptographic processing mechanism for $ 
processing the return message and HTML doc- 
uments in accordance with a specified crypto- 
graphic protocol; 

wherein the web browser utilizes the browsing 
mechanism to receive and transmit the return io 
message to and from the server computer and 
utilizes the cryptographic processing mecha- 
nism to exercise one or more cryptographic 
protocols on the HTML documents and return 
message in order to enable receipt of the HTML is 
documents by an intended user associated with 
the client computer and to provide secure trans- 
mission of the return message transmitted to 
the server computer. 

20 

6. The web browser of claim 5, 

the cryptographic processing mechanism in- 
cluding an encryption processing mechanism for 
encrypting the return message and decrypting 
HTML documents. 25 

7. The web browser of claim 5, 

the cryptographic processing mechanism in- 
cluding a digital signature processing mechanism 
for signing the return message and authenticating 30 
HTML documents. 

8. A computer network for financial transaction 
processing, the network comprising: 

35 

a plurality of client computers, each client com- 
puter associated with one or more users; 
at least one financial server comprising: 

a memory for storing a plurality of HTML 40 
documents representing financial transac- 
tions, each HTML document including form 
data, a subset of the HTML documents in- 
cluding cryptographic protocol directives 
for use in exchanging financial transac- 45 
tions between the client computers and the 
server computer; 

one or more cryptographic processing 
mechanisms for use in encoding said form 
data and decoding each received HTML so 
document; and 

a server mechanism for managing commu- 
nications from the client computers, a sub- 
set of the communications including a re- 
turn message including the form data, the 55 
server mechanism including instructions to 
interpret the cryptographic protocol direc- 
tives associated with each received return 



message and to process each received re- 
turn message in accordance with one or 
more corresponding cryptographic proto- 
col mechanisms. 

9. The network of claim 8, 

the cryptographic processing mechanism in- 
cluding: 

an encryption processing mechanism for en- 
crypting the form data and decrypting the HTML 
documents; 

a user information database that includes user 
public key information associated with each us- 
er registered to exchange confidential informa- 
tion with the financial server; 
a digital signature verification mechanism for 
verifying a digital signature in each digitally 
signed communication received from a client 
computer in accordance with the correspond- 
ing digital signature, if any, stored in the user 
information database; and 
an audit trail for storing records of digitally 
signed communications received from client 
computers sufficient to prove that such each re- 
ceived communication was digitally signed by 
a respective user registered to exchange con- 
fidential information with the financial server. 

10. The method of claim 3, 

step (c)(4) further including the step of obtain- 
ing the second encryption key from the server com- 
puter. 

11. The method of claim 3, 

step (c)(1 ) further including the step of: 

prior to the generating step, storing a 
digital signature associated with a specified user in 
the return message. 

12. The method of claim 11 , 

step (c) further including the steps of: 

generating a digital signature and a digital sig- 
nature verifier; and 

providing the server computer with the digital 
signature verifier. 

13. The method of claim 1, 

step (c) further including the step of storing a 
timestamp in the return message. 

14. The web browser of claim 7, 

the digital signature processing mechanism 
including a timestamp processing mechanism. 

15. The web browser of claim 5, 

the cryptographic processing mechanism in- 
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eluding an encryption key generation mechanism 
for creating one or more encryption keys. 

16. The web browser of claim 15, 

the encryption key generation mechanism in- 
cluding a random key generation mechanism for 
creating one or more random session keys. 

17. A computer readable storage medium containing a 
computer code mechanism for use with a financial 
server, the computer code mechanism comprising: 

a browsing mechanism for retrieving HTML 
documents from the financial server, said 
HTML documents including form data, said 
browsing mechanism inserting user related in- 
formation in said form data which is appended 
to a return message that is transmitted to the 
financial server, a subset of the HTML docu- 
ments retrieved from the financial server includ- 
ing cryptographic protocol directives for use in 
exchanging return messages to the financial 
server; and 

a cryptographic processing mechanism for 
processing the HTML documents in accord- 
ance with a specified cryptographic protocol; 
wherein the computer code mechanism utilizes 
the browsing mechanism to receive HTML doc- 
uments from the financial server and to transmit 
return messages to the financial server and uti- 
lizes the cryptographic processing mechanism 
for exercising one or more cryptographic proto- 
cols on the HTML documents in order to enable 
receipt of the received HTML documents by an 
intended user and to ensure secure transmis- 
sion of the return message transmitted to the 
financial server. 

18. The medium of claim 17, 

the cryptographic processing mechanism in- 
cluding an encryption processing mechanism for 
decrypting HTML documents and encrypting the re- 
turn message. 

19. The medium of claim 17, 

the cryptographic processing mechanism in- 
cluding a digital signature processing mechanism 
for signing the return message and authenticating 
the HTML documents. 

20. The medium of claim 19, 

the digital signature processing mechanism 
including a timestamp processing mechanism. 

21. The medium of claim 17, 

the cryptographic processing mechanism in- 
cluding an encryption key generation mechanism 
for creating one or more encryption keys. 



22. The medium of claim 21 , 

the encryption key generation mechanism in- 
cluding a random key generation mechanism for 
creating one or more random session keys. 

5 

23. The network of claim 9, 

the cryptographic protocol directives selected 
from the set consisting of encryption, digital signa- 
ture and timestamp, and encryption with digital sig- 
10 nature and timestamp. 

24. The network of claim 9, 

each client computer including a web browser 
for accessing HTML documents from the financial 
15 server. 

25. The network of claim 24, 

the web browser including a cryptographic 
processing mechanism for encrypting form data 
20 and decrypting the accessed HTML documents. 

26. The network of claim 24, 

the web browser including a digital signature 
processing mechanism for signing the return mes- 
25 sage and authenticating HTML documents. 

27. The network of claim 26, 

the digital signature processing mechanism 
further including a timestamp processing mecha- 
30 nism. 

28. The network of claim 24, 

the web browser including an encryption key 
generation mechanism for creating one or more en- 
35 cryption keys. 
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